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1. Introduction 

A safety property of a program asserts that some proscribed "bad thing" does not occur during 
execution. To prove that a program satisfies a safety property, one typically employs an invariant, a 
characterization of current (and possibly past) program states that is not invalidated by execution. If 
an invariant / holds in the initial state of the program and / => Q is valid for some Q, then Q cannot 
occur during execution. Thus, to establish that a program satisfies the safety property asserting that 
-i Q does not occur, it suffices to find such an invariant /. 

Timing properties are safety properties where the "bad thing" involves the time and program 
state at the instants that various specified control points in a program become active. 1 Timing proper- 
ties can restrict externally visible events, like inputs and outputs, as well as things that are internal to 
a program, like the value of a variable or the time that a particular statement starts or finishes. For 
example, in a process control system, the elapsed time between a stimulus and response must be 
bounded. This is a timing property where the "bad thing" is defined in terms of the time that passes 
after one control point becomes active until some other control point does. Timing properties con- 
cerning internal events are useful in reasoning about ordinary concurrent programs that exploit 
knowledge of statement execution times to coordinate processes. One such protocol — for mutual 
exclusion — is given in section 4. 

Because timing properties are safety properties, the invariant-based method outlined above for 
reasoning about safety properties can be used to reason about timing properties. This means that a 
programming logic L to verify (ordinary) safety properties can form the basis for a logic L' to verify 
timing properties. It suffices that in V we are able to 

(1) specify in I and Q information about the times at which events of interest occur and 

(2) establish that program execution does not invalidate such an I. 

Point (1) means that in defining L', the language of L might have to be extended so that it becomes 
more expressive. Point (2) means that the inferencing apparatus of L might have to be refined so that 
/ can be proved an invariant for a program whose semantics includes information about execution 
timings. 

This paper describes extensions to a logic of proof outlines [Schneider 92] to enable verification 
of timing properties for concurrent programs. The approach taken is the one just outlined: we start 
with a logic for proving ordinary safety properties, augment the language according to (1) and refine 
the inference rules according to (2). The presentation is organized as follows. In section 2, we 
describe a logic of proof outlines. Section 3 introduces and axiomatizes a new type of atomic action, 
called a real-time action. The correctness proof for a mutual exclusion protocol in section 4 illus- 
trates the use of our logic. Related work and some unresolved technical issues are discussed in sec- 
tion 5. 

2. Proof Outlines 

In order to reason about a program, we must be able to define sets of program states and reason 
about them. First-order predicate logic is an obvious choice for this task, and we employ the usual 

'Informally, the active control points at any instant are determined by the values of the program counters at that in- 
stant. See §2 for a more formal definition. 
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correspondence between the formulas of the logic and the programming language of interest — each 
variable and expression of the programming language is made a term of the logic and each Boolean 
expression of the programming language is made a predicate of the logic. It will be convenient to 
assume that predicates and terms are always defined, although the value of a term may be unspecified 
in some states. For example, we will assume that the term xly has a value whatever value y has, but 
that y *(x/y) need not equal x when y is 0 because the value of xly is unspecified in such states. 

Predicates and function symbols for the programming language’s data types provide a way to 
express facts about program variables and expressions. The state of a program, however, also 
includes information that tells what atomic actions might be executed next For representing this 
control information, we will find it convenient to fix some predicate symbols, called control predi- 
cates, and give axioms to ensure that, as execution proceeds, changes in the values of these 
correspond to changes to program counters. (An alternative representation would have been to define 
a "program counter" variable and a data type for the values it can assume.) 

2.1. Control Predicates 

A program consists of a set of atomic actions, each of which executes as a single indivisible 
state transformation. The control points of the program are defined by these atomic actions. Each 
atomic action has distinct entry control points and exit control points. For example, the atomic action 
that implements skip has a single entry control point and a single exit control point; the test for an if 
has one entry control point and one exit control point for each alternative. Execution of an atomic 
action a can occur only when an entry control point for a is active. Among other things, execution 
causes that active entry control point to become inactive and an exit control point of a to become 
active. 

For each statement or atomic action 5, we define the following control predicates: 
at(S): an entry control point for S is active. 

after(S): an exit control point from S is active. 

The various statements in a programming language give rise to axioms relating these control predi- 
cates. The axioms formalize how the control predicates for a statement or atomic action S relate to 
the control predicates for constructs comprising S and constructs containing S, based on the control 
flow defined by S. For a guarded-command programming language [Dijkstra 75], these axioms are 
given in Figure 2.1. We use G Eval^S) there to denote the guard evaluation action for an if and 
GEvaldoiS) to denote the guard evaluation action for a do. And, we write P\ © P 2 © ... . © P n to 
denote that exactly one of P \ through P n holds. 

2.2. Syntax and Meaning of Proof Outlines 

A proof Ratline PO(S) For a program S is a text in which every atomic action of S is preceded 
and followed by an assertion enclosed in braces (”{” and Each assertion is a Predicate Logic 
formula in which 

• the free variables are program variables (typeset in italics) or rigid variables, (typeset in upper- 
case roman), and 

• the predicate symbols are control predicates or the predicates of the programming language’s 
expressions. 
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Atomic action : For 5 a skip, guard evaluation action, or assignment: 

-i (at(S) a after{S)) 

Sequential composition : For S the sequential composition Si S 2 : 

(a) <iiCS) ««*$!) 

(b) after(S ) = afteriSi) 

(c) (rftetiS i) = ar(S 2 ) 

if Control Axioms: For an if statement: 

S: if B\ - 4 Si 0 5 2 — »S 2 Q • • • Q — >S, fi 

(a) ar(S) = at(GEval ^S)) 

(b) aftetiS ) = ( after(S \ ) © aftetiS i) © ... © after(S n )) 

(c) after(GEval jfiS)) = (ar(S i ) © a/(S 2 ) © ... © at(S n )) 

do Control Axioms: For a do statement: 

S : do B \ — > S i Q B 2 — *S 2 Q Q B„ — > S„ od 

(a ) atiGEvaljoiS)) = (ar(S) © q/feK<Si) © q^er(S 2 ) © ... ©q^reKS,)) 

(b) afteripEvaldoiS )) = (ar(S i) © ar(S 2 ) © ... © at(S B ) © after(S)) 

cobegin Control Axioms: For a cobegin statement: 

S: cobegin Si II Si II // S„ coend 

(a) o/(S) = (<u(Si) a ... a at(S n )) 

(b ) after{S) = (afteiiS \ ) a ... a after(S n )) 

Figure 2 . 1 . Control Predicate Axioms 


Assertions in which all terms arc constructed from program variables, rigid variables, and predicates 
involving those variables are called primitive assertions. An example of a proof outline appears in 
Figure 2.2. In it, x is a program variable and X is a rigid variable. All assertions except the first and 
last are primitive. 

The assertion that immediately precedes a statement or atomic action Tin a proof outline PO(S) 
is called the precondition of T and is denoted pre(T): the assertion that directly follows T is called the 
postcondition of T and is denoted by post(T). For the proof outline in Figure 2.2, this correspondence 
is summarized in Figure 2.3. Finally, for a proof outline PO(S), we write pre(PO(S)) to denote 
pre(S), post(Pd(S)) to denote post(S), and use a triple 

(2.1) {P)PO{S){Q) 

to specify the proof outline in which pre(S) is P, post(S ) is Q, and all other pre- and postconditions 
are the same as in PO(S). 

A proof outline PO{S) can be regarded as associating an assertion pre(T) with control predicate 
at(T) and an assertion post(T) with after(T) for each statement T in a program fragment 5. 
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[x=Xa at(S)} 

S: if x>0 — > {x=X a x £ 0 } 

Si: skip 
(j=Xa^O} 
0^O-^(j=Xa^O} 

S 2 : x := -x 
{-x=Xa-xZO} 
fi 

{j:=a6s(X) a afteiiS)} 

Figure 2JL Computing abs(x ) 


Assertion 

Assertion Text 

pre{S) 

x=X a at(S) 

post{S) 

x=abs(X) a after(S) 

pre(S\) 

x=X axIlO 

postiS i) 

x=XaxZO 

pre(S 2 ) 

jc=XaxSO 

post(S 2 ) 

-x=X A -x£0 


Figure 23. Assertions in a Proof Outline 


Consequently, a proof outline defines a mapping from each control point A. of a program to a set of 
assertions — those assertions associated with control predicates that are true whenever X is active. In 
most cases, a control point is mapped to a single assertion. For example, the proof outline 

(2.2) {/>] Sj { Q ) S 2 {*} 

maps the entry control point for program Si S 2 to the single assertion P. This is because at(S\) and 
at(S\ S 2 ) are the only control predicates that are true if and only if the entry control point for Si S 2 is 
active, and (2.2) associates P with both of these control predicates. However, a proof outline can map 
a given control point to multiple assertions. An example of this appears in Figure 2.2. There, the exit 
control point for Si is mapped to two assertions — post(S\) and post(S ) — because whenever the exit 
control point of S i is active both aftertS \ ) and after(S) are true. 

The assertions in a proof outline are intended to document what can be expected to hold of the 
program state as execution proceeds. The proof outline of Figure 2.2, for example, implies that if 
execution is started at the beginning of S i with x=23 (a state that satisfies pre(S i )), then if S i com- 
pletes, post(S\) will be satisfied by the resulting program state, as will post(S). And if execution is 
started at the beginning of S with x=X, then whatever assertion is next reached — be it pre(S\) 
because X£0 or pre(S 2 ) because X£0 — that assertion will hold when reached, and the next assertion 
will hold when it is reached, and so on. 

With this in mind, we define a proof outline PO(S) to be valid if it describes a relationship 
among the program variables and control predicates of S that is invariant and, therefore, not falsified 
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by execution of S. The invariant defined by a proof outline PO(S ) is "if a control point X is active, 
then all assertions that X is mapped to by PO(S) are satisfied" and is formalized as the proof outline 
invariant for PO(S): 

(2.3) Ipo(S)'- A ((at(T) => pre(T)) a (after(T) => post(T ))) 

For example, the proof outline invariant defined by PO(S) of Figure 2.2 is 

at(S) =* (x=X a ar(S)) a after{S) => (x=abs(X) a after{S )) 
a ar(5i)=^(x=XAx^0) a after(S i)=»(x=Xax^0) 
a <w(52)=^(x=Xax^0) a after(S2) : ^(-x=X/\-x£0). 

Equating proof outline validity with invariance of lpo(S) can have disturbing consequences for 
proof outlines that map a single control point to multiple assertions. The following valid proof out- 
line illustrates this. 

(2.4) [false] 

S : if true — > [false] S': x:=3 {x=l}fi 
[x=2] 

This proof outline maps the exit control point for S' to two assertions, posts') and post(S). The 
proof outline is valid because Ipo{S) 

at(S)=> false a afteriS) => x=2 
a Otis') => false a afteriS") => x=l 

is equivalent to false (since afteriS^-cfteriS) is valid) and therefore Ipots) cannot be falsified by exe- 
cution of any statement The problem with (2.4) is that post(S), the assertion associated with the exit 
control point of 5, is not implied by postiS'), the assertion associated with the exit control point for 
the last atomic action in S (i.e S'). As a result, what (2.4) really associates with the exit control point 
for S' (viz. posies') a post(S)) is not accurately characterized by post(S). Given a valid proof outline 
PO(S), it seems reasonable to expect post(S) to hold whenever an exit control point of S is active. 
Similarly, pre(S) should be constrained so that if it holds and an entry control point of S is active, 
then assertions that PO(S) associates with that entry control point also hold. To formalize these con- 
straints, we define a proof outline PO(S) to be self consistent if and only if 

(2.5) at(S) a pre(S) => IIpo(s ) 

(2.6) afteriS) a Hpo(S) => post{S) 
where 

Hpo(S) ■ A ((at(T) =* pre(T)) a ( afteHT) => post(T))) 

T*S 

Upo(S) is just Ipo(S) with the two conjuncts concerning pre(S) and post(S) (i.e. "at(S)=>pre(Sy and 
”after(S)=>post(S)") omitted. 2 Thus, (2.5) ensures that whenever any entry control point X for S is 
active, if pre(S) holds then so does the assertion that PO(S) associates with X. And (2.6) ensures that 
whenever any exit control point X of S is active, if the assertion associated with that control point 
holds then post(S) will hold as well. Together, (2.5) and (2.6) mean that pre(S) and post(S) consti- 
tute a reasonably complete interface to S: provided pre(S) holds when execution of S is started, the 
assertions of PO(S) will characterize any states that arise as execution proceeds and post(S) will hold 

2 // is an acronym for internal invariant. 
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if an exit control point for S is ever reached. It should come as no surprise that the proof outline of 
(2.4) is not self consistent — (2.6) is violated. 

The requirements for validity of a proof outline — invariance of Ipo{S) and self-consistency — can 
be formalized in terms of -validity of Temporal Logic formulas, where Ms is the set of infinite 
state sequences that model execution of S started from any program state [Owicki-Lamport 82]. In 
this formalization, we are able to write Ms in order to denote that a Predicate Logic formula P is 
valid because every program state is the first state of some interpretation in Ms . 

(2.7) Valid Proof Outline, A proof outline PO(S) is valid if and only if: 

Self Consistency’. Ms*=(at(S) a pre(S ) => IIpo(S)) 

Ms^(after(S) a H P0 (S) => post(S)) 

Invariance: Mst=(Ipo(S) => □^/’O(S)) □ 

Notice that according to Valid Proof Outline (2.7), rigid variables in proof outlines can be used 
relate the values of program variables from one state to the next. This is because free rigid variables 
in a temporal logic formula are implicitly universally quantified. Thus, Ipo(S) => □ ho{s ) *s M$ -valid 
if and only if for any assignment of values to the proof outline’s rigid variables, execution of S starts 
in a state that does not satisfy Ipo(S) or results in a sequence of states that each satisfy Ipo(S)- 

For example, the proof outline of Figure 2.2 is valid and contains a rigid variable X to record the ini- 
tial value of x. Starting execution in a state where atiSi) and x=-23 holds will satisfy 
Ip 0 (s) => even if -23 is not assigned to X because then Ipo(S) is not satisfied (causing 

bow => □//><? cs) to be trivially satisfied). 

2.3. Axiomatization for a Proof Outline Logic 

Proof Outline Logic is an extension of Predicate Logic. The language of Predicate Logic is 
extended with proof outlines for all atomic actions, statements, and programs. The axioms and infer- 
ence rules of Predicate Logic are extended with axioms and inference rules that allow only valid 
proof outlines to be proved theorems. In particular, there are some statement-independent inference 
rules as well as an axiom or inference rule for each type of statement and atomic action. 

The statement-independent inference rules for Proof Outline Logic are given in Figure 2.4. 
Rule of Consequence allows the precondition of a proof outline to be strengthened and the postcondi- 
tion to be weakened, based on deductions possible in Predicate Logic. Rule of Equivalence allows 
assertions anywhere in a proof outline to be modified, provided a self consistent proof outline having 
an equivalent proof outline invariant results. A rigid variable can be renamed or instantiated by using 
the Rigid Variable Rule; PO(S)b p in the conclusion of that rule denotes a proof outline in which 
rigid variable X in every assertion is replaced by Exp, an expression involving constants and rigid 
variables (only). Finally, the Conjunction and Disjunction Rules allow two proof outlines for the 
same program to be combined. PO A (S)QPO B (S) is used to denote the proof outline that associates 
assertion A cp a B cp with each control predicate cp, where X cp is the assertion that POx(S) associates 
with control predicate cp; PO A (S)QPO B (S) denotes the proof outline that associates A cp v B cp with 
each control predicate cp 

We now turn to the axiomatization for a concurrent programming language. The skip statement 
is a single atomic action whose execution has no effect on any program variable. 
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Rule of Consequence: 


Rule of Equivalence: 


P'^P. (JMPOCSHQ). (2 => C2' 

{P') PO(S ) {Q'} 


PO(S), Ipoqs) = Ipo'(S)’ PO'(S) self consistent 
PO'iS) 


Rigid Variable Rule: For Exp an expression involving only constants 
and rigid varibles: 

[Pipo^xm 

/W)Lp [Qlp) 


Conjunction Rule: 


POa^\ POb(.S) 
PO a (S)QPO b (S) 


Disjunction Rule: 


POaOS)' POb(S) 
PO a (S)QPO b (S) 


Figure 2.4. Proof Outline Logic: Statement-independent Rules 


skip Axiom: For a primitive assertion P: [P } skip [P } 


The assignment statement x := E is also a single atomic action. Its execution involves evaluat- 
ing E and then storing that value in x? 

Assignment Axiom: For a primitive assertion P: (Pf } x :=e {/»} 


Sequential composition of statements is denoted by juxtaposition (without the traditional semi- 
colon separator). 


Statement Composition Rule: 


[PyPO^xliOh [QVPO^M ^ } 

{/>}P0(S,){G}P0(S 2 ) {R} 


An if statement consists of an atomic guard evaluation action that selects for execution an alter- 
native whose guard is true: if no guard is true, then the guard evaluation action blocks. We use the 
following rule for reasoning about a guard evaluation action. 


3 For simplicity, we restrict consideration to the case where x is a simple identifier and not an array. See [Gries-Levin 
80 ] for the more general rule. 
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GEval t f(S) Axiom: For an if statement 

S ; if 5 1 — > 5 j [] f?2 — > S 2 D ' ■ ■ 0 B n — * S n fi 
and a primitive assertion P : 

{?} GEval^S ) [P a ((artfO^S,) a ... a (ar(S,,)=>B„))} 

A proof outline for an if is then constructed by combining a proof outline for its guard evaluation 
action with a proof outline for each alternative. 

if Rule: (a) (P) GEval^S) (R), 

(b) (/? A Ot(S 1 )) ^ P It • ••> (R A ^ P n , 

(c) {P„}PO(S,){{2}, 

{P) 

S: if Bi->{/>i}PO(S,){Q} 

□ ••• 

D B n ^(P n )PO(S n )(Q] 

fi 

(Q) 


Since the guard evaluation action for an if blocks when no guard is true, we can use an if to 
implement conditional waiting. For example, 

if B -» skipfi 

blocks until the program state satisfies B. 

The guard evaluation action for do selects a statement S, for which corresponding guard B t 
holds and if no guard is true, then the control point following the do becomes active. 

GEvaldoiS) Axiom : For a do statement 

S : do 5 1 — ► S j Q B2 — ► S2 0 ' ' ' D B n — > S n od 
and a primitive assertion P: 

{/>} GEval^S) (Pa ((at(S x )=>B X ) a ... a (at(S n )=>B n ) 

a (after(S)^(— \B X a ... a-iB„)))} 

The inference rule for do is based on a loop invariant, an assertion / that holds before and after every 
iteration of a loop and, therefore, is guaranteed to hold when do terminates — no matter how many 
iterations occur. 

do Rule: (a) (I } GEval^S) (R), 

(b) (/?Aar(S 1 ))=>/ , i, ... (RAat(S n ))^P n , 

(c) {?,}PO(5i){/}. .... {P„}PO(S„){/} 

(d) (R a ctfteriS)) => (/ a-,5, a ... a ^B n ) 

(/} 

S: do 5, {PiJPOCSO {/} 

□ 

D B n ->(P n }PO(S n ) {/} 
od 

{/ A— tB\ A ... A — 1 B n } 
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The inference rule for a cobegin is based on combining proof outlines for its component 
processes. An interference- freedom test [Owicki-Gries 76] ensures that execution of an atomic action 
in one process does not invalidate the proof outline invariant for another. This interference-freedom 
test is formulated in terms of triples, 

W(o,A): [pre(a)*A) a {A}, 

that are valid if and only if a does not invalidate assertion A. If no assertion in PO(Si) is invalidated 
by an atomic action a then, by definition, Ipo@ t ) also cannot be invalidated by a. Therefore, we can 
prove that a collection of proof outlines PO(S\) PO(S n ) are interference free by establishing: 

Foralli.y, l^r^n, l£/£n, i*/: 

For all atomic actions a in 5,- : 

For all assertions A in PO(Sj): NI(cl,A) is valid. 

The following inference rule determines when a valid proof outline for a cobegin will result from 
combining valid proof outlines for its component processes: 

cobegin Rule: (a) PO(S i), .... PO(S n ) 

(b) P^pre(PO(S x )) a ... a pre(PO(S n )), 

(c) post(PO(S i)) a ... a post(PO(S n )) =$ Q, 

(d) PO(S i), .... PO(S„) are interference free. 

{/>} cobegin POtf,) //'•••■ // P0(S„) coend (Q} 

Since execution of an atomic action a in one process never interferes with a control predicate cp 
in another, certain interference-freedom triples follow axiomatically. 

Process Independence Axiom: For a control predicate cp in one process and an atomic 
action a in another: 

{ cp-C } a [cp= C} 

Notice that NI(a, cp) follows directly from this axiom when a and cp are from different processes. 

2.4. From Proof Outlines to Safety Properties 

Theorems of Proof Outline Logic can be used to verify safety properties because of the way 
proof outline validity is defined. If a proof outline PO(S ) is valid then Ipo(S) must be an invariant. 
And, if Ipo(S) is an invariant, then according to the method of §1 for proving safety properties we can 
prove that executions of 5 starting with pre(PO(S)) true will satisfy the safety property proscribing 
— i Q. We simply prove 

(2.8) (cp a A cp ) => Q 

for every assertion A cp in PO(S), where A cp is the assertion that PO(S) associates with control predi- 
cate cp. For example, we prove as follows that for the absolute value program in Figure 2.2, 
after(S ) => X = abs (X) holds during executions started in a state satisfying at(S) a x-X: First, because 
post(S) => x=abs(X) is valid, for the case where cp is after(S ), (2.8), which is 

after(S) a post(S) => (after(S) =>x=abs(X)), 
is valid. Second, for the case where cp is not implied by qfter(S), (2.8) is trivially valid. 
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3. Real-time Actions 

We must know something about the execution times of atomic actions in order to reason about 
timing properties of programs. Therefore, for each unconditional atomic action 4 a in our program- 
ming language, we define corresponding real-time actions e j where 5 and e are real-valued, non- 
negative constants. Execution of a real-time action 045, E j causes the same indivisible state transfor- 
mation as a does, but constrains it to occur at some instant between e and e+5 time units after the 
entry control point for 0(8, £ ] becomes active. 

We have elected to characterize the execution time for a real-time action in terms of two param- 
eters (5 and e) in order to have flexibility in modeling various execution environments. Parameter e 
describes the fixed execution time of the atomic action on a bare machine; 5 models execution delays 
attributable to multiprogramming and other resource contention. A system where each process is 
assigned its own processor is modeled by choosing 0 for 5; a system where processors are shared is 
modeled by choosing a value for 5 based on the length of time that a runnable process might have to 
wait for a processor to become available. 

3.1. Reasoning About Real-time Actions 

Execution of a real-time action CC(5, e j affects the program variables and control predicates in the 
same ways as the atomic action a from which it was derived. Therefore, we have the following infer- 
ence rule; 

Real-time Action Transformation: For a an unconditional atomic action, P and Q primitive 
assertions, and 0^5 and 0£e: 

[P )a(Q) 

[/»} Ots.e] [Q] 

To reason about timing properties, additional terms must be added the assertion language. This 
is because the method of §2.4 for reasoning about safety properties can only be used to prove safety 
properties for which the negation of the proscribed -1 Q is implied by each of a proof outline's asser- 
tions. Timing properties concern the instants at which control predicates become active and so we 
define a term for each control predicate cp: 

{ the time that cp last became true or 
-00 if cp has never been true 

We also define a new real-valued term T to be equal to the current time. 

Some additional axioms and inference rule allow us to reason about formulas of our more 
expressive assertion language. First, the various non-atomic statements of our programming 
language give rise to axioms based on the way they equate their components’ control points. For our 
programming language, these axioms are given in Figure 3.1. Second, there are some language- 
independent axioms. In these, cp and cp' can denote any control predicates, including those not asso- 
ciated with entry or exit control points for real-time actions. 

4 An atomic action is unconditional if it is executable whenever its entry control point becomes active. In the program- 
ming notation of §2.3, skip, assignment, and the guard evaluation action for do are unconditional. The guard evaluation for 
if is not unconditional. 
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Sequential Composition Axioms-. For S the sequential composition S t $2: 

(a) T at(S) = tat(Si) 

(b) t after{S) = iafter(S 2 ) 

(c) ^ after (S 1 ) = tat(S 2 ) 

if Axioms : For an if statement: 

S: it B i -*S i G B 2 — > S 2 D ■*' D B n S a 6 

(a) r<a(S) = t at(GEval ^S)) 

(b) tafter(S) = max(t after(S 1), lafter(S 2 ), .... tqfter{S H )) 

(c) laftertGEvalyiS )) = max(Tar(Si), Taf(S2), ...tat(S n )) 

do Axioms'. For a do statement: 

S : do B \ —+ S 1 Q B 2 — * S 2 D ' * ■ 0 B n — ► S n od 

(a) t atipEval doiS)) = max(Tar(S), iqfter{S 1 ), tafter(S 2 ), .... tafter{S n )) 

(b) t afteriGEval joiS)) = max(T at(S 1), tat(S 2 ), .... TatCS,,), t after(S)) 

cobegin Axioms: For a cobegin statement: 

S: cobegin Si II S 2 II ••• // S„ coend 

(a) Tar(S) = Tor<Si) = *” =t ar(S„)) 

(b) rafter(S) = max(Ta/irer(Si). .... iafter{S n )) 

Figure 3.1. tcp Axioms 


(3.1) t cpzrr 

(3.2) (Tcp = - 00 ) => -,cp 

(3.3) For a real time action £) with label S: (a) at(S) => iat(S) £ T<, Tar(S)+S+e 

(b) Tat(S)*-°° => tc0eriS)^tat(S)+6+£ 

Axioms (3.1) and (3.2) follow directly from the definition of Tcp. Axiom (3.3) captures that essence 
of a real-time action — that its entry control point cannot stay active too long. This, in turn, allows us 
to infer that a control point is not active by using 

(3.4) T>r a*S)+8+e => ^aKS) 

because from (3.3a) we have: 

a/(S ) => tat(S)^T^tat(S)+5+e 
= « Predicate Logic* 

ar(S) ((Ta^S)^*!) a ( < 25Ta/(S)+5+e) 

= « Predicate Logic* 

((Tar(S) > T) v (T> tar(S)+5+e)) => -,at(S) 

= « Axiom (3.1)» 

T>Tar(S)+5+e => ->at(S) 
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The effect on these new terms of executing atomic actions is captured by the following axioms 
of Proof Outline Logic. First, for any ordinary or real-time atomic action, we have: 

t cp Invariance'. {cp=C a tcp=V} S : a {(cp =>C) => (T cp=V)} 

The antecedent in the postcondition is necessary for the case where cp is <rfter(S), since executing 5 
does change the value of after(S). 

Next, for any ordinary atomic action: 

Action-time Axioms', (a) {K£tar(S)} S:a [YLZtaftetiS)} 


(b) {KST} 5: a (K£tctfter(S)} 

Action-time Axiom (a) asserts that the exit control point for 5 becomes active after any of its entry 
control points last became active. Action-time Axiom (b) asserts that the exit control point of S 
becomes active later than any time that the entry control point for 5 was last active. 

For a real-time action £] , the following axiom characterizes how execution changes Tand 
the rcp-terms. 

Real-time Action Axiom {K£Tar(S)} S : e j {K+e^ta/rer(5)} 

This axiom is analogous to Action-time Axiom (a), except now the postcondition has been 
strengthened to give a tighter lower bound on when the exit control point for S first becomes active. 

Two things that the Real-time Action Axiom does not say are worthy of note. First, this axiom 
does not bound the interval during which the entry control point for S is active. This is because that 
bound already can be derived using axiom (3.3a), since at(S) holds whenever the entry control point 
for S does. Second, one might expect to be able to prove the following triple — its precondition being 
similar to that of Action-time Axiom (b). 

(3.5) {KST} S:<X( 5 , E ] (K+eST) 

Unfortunately, (3.5) is not sound. Execution of S started in a state such that tar(<x)<K£T would 
satisfy the precondition but might terminate before K+e. For example, consider an execution of 
O[o. 2 ] that is started at time 0. Thus, at time T=1 the state would satisfy K£T for K=l, and so 
precondition K^Twould be satisfied by that state. When execution of O[o, 2 ] terminates — 2 units after 
it is started — at time T=2, the postcondition K+e£T is 1+2^2, which is false. 

Finally, the following rule allows rigid variables to be instantiated with expressions involving 
tcp-terms. (Rigid Variable Rule only allows rigid variables to be instantiated by constants, rigid vari- 
ables, or expressions constructed from these.) 


r cp-Instantiation 


(rcp=V) a (Tcp=V), {/>} a{(2} 


This rule is typically used along with one of the Action-time Axioms or the Real-time Action Axiom. 
For the case where real-time action q and control predicate cp are in different processes, the first 
hypothesis of tcp-Instantiation is automatically satisfied, as the following proof of 
{rcp=V} q {tcp=V} demonstrates. 

Process Independence Axiom: 

1. (ar(p)=C) q MP)=C) 


- 12 - 


t cp Invariance: 

2. {<«(f3)=C a t ar(P)=V} a {(ar(p) =>C) => (tar(p)=v)} 

Conjunction Rule with 1 and 2: 

3. {<w(P)=C a taf(P)= V} a {ar(p)=C a ((atf(5) =>C) => (Tat(fi)=V))} 

4. at( P)=C a ((ar(P) =>C)=> (Tar(P)=V)) 

=> «Predicate Logic* 
ror(P)=V 

Rule of Consequence with 3 and 4: 

5. {a/(P)=C a T<zf(P)=V} a {Tar(p)=V} 

Rigid Variable Rule with 5, replacing C by true and then by false: 

6. (at(P) a ta/(P)=V} a (tar(p)=V) 

7. {-ia/(P) a Tar(P)=V) a {tar(p)=V} 

Disjunction Rule with 6 and 7: 

8. {(ar(P) v ->ar(P)) a Tnr(P)=V} a {tar(P)=V} 

Equivalence Rule with 8: 

9. {t<tf(p)=V} a {^P)=V} 

Thus, we obtain a derived rule of inference: 

Derived tcp-Instantiation: If atomic action a and control predicate cp are in different 
processes: 

£ 1*101 

[Pip) *{Ql P ) 


3.2. Interference Freedom Revisited 

When the execution times of atomic actions are bounded, certain forms of interference cannot 
occur. This is illustrated by the proof outline 

{*= 0 } 

cobegin 

{*=0} a: (x :=x+l) [0(2 ] {*=1} 

II 

{*=0} P: (y :=x+l){ 0 , i] {y=l} 

coend 

{x=l Ay=l} 

which is valid but cannot be derived using the cobegin Rule because PO (a) and PO (P) are not 
interference free. In particular, NI( a, pre{ P)) is not valid. 

Nl(a,prem 

= (pre(a) Apre(p)} (x :=x+l) [0 ,2] ip™( P)} 

- {x=0} (x :=x+l) [0 , 2 ] {x=0} 

Using operational reasoning, however, it is not difficult to argue that execution of a cannot invalidate 
pre(p) and so PO(a) and PO( P) should be considered interference free. This is because according to 
cobegin Axiom (b) in Figure 3.1 both at(ct) and nr(P) become active at the same instant, say time 0. 
By definition, a completes at time 2, and so x remains 0 until this time. Real-time action P completes 
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at time 1 and, therefore, must find x to be 0. It is simply not possible for a to change the value of x 
while ar(P) is active. 

Our cobegin Rule is based on a form of interference freedom that does not take into account 
execution-time bounds of real-time actions. In particular, NI(a, A cp ) does not account for the fact 
that although Aq, might be associated with an active control point cp when a is started, if A is the 
precondition of a real-time action then we may be able to prove that cp cannot be active when a com- 
pletes. The remedy is to refine A7(a, A cp ) taking into account the time bounds for how long an entry 
control point for a real-time action can remain active. The following triple accomplishes this. 

A/7«( a, Acp): [at(a) a pre( a) a cp *A cp ) a [cp => A cp } 

Returning to the example above, we have: 

Nl^prem 

- (ar(a) a pre(a) a ar(p) a pre(fi ) } (x := x+ 1 ) [0 , 21 MP) => pre( P)} 

* (ar(a) Aar(p) ax= 0} (x :=x+l> (0 ,2j Mp)=>x=0] 

And, this obligation can be discharged as follows. 

Real-time Action Axiom: 

1. (K£T<w(a)} cc (x :=x+l)[o, 2 ] {K+2£rqfirer(o0} 

Derived Tcp- Instantiation with 1: 

2. (tar(P)^Tar(a)} a: (x :=x+l)[ 0t 2 ] { tar(P) + 2 <1 tqfter(a ) } 

Axiom (3.1): 

3. Tqfter(a)£T 

Rule of Consequence with 2 and 3: 

4. (tar(P)^rar(a)} a: <x :=x+l> [0 , 2 ] {tar(P)+2£T} 

Axiom (3.3a): 

5. arfl3) => tar(P) £ T:£ Tar(P)+ 1 

Predicate Logic: 

6. ((rar(p)+2^T) a (ar(P) => tar(P)^T^Tar(P)+l)) => -.atfp) 

Rule of Consequence with 4, 5, and 6: 

7. (rar(p)^tar(a)) a: <x :=x+l> [0 , 2 ] {->ar(P)} 

Predicate Logic and tat(a)=rat(b) from cobegin t cp Axiom (a): 

8. pre(NI n {a, pre($)) => TarfPl^Tarta) 

9. a/(P) => postal rt { cc, pre(P))) 

Rule of Consequence with 7, 8, and 9: 

10. NI n (a,prem 

4. Example: A Mutual Exclusion Protocol 

Knowledge of execution times can be exploited to synchronize processes. A mutual exclusion 
protocol attributed in [Lamport 87] to Mike Fischer illustrates this point. The core of this protocol 
appears in Figure 4.1. There, c, d, c' and d' are real-time actions. Provided the parameters of these 
real-time actions satisfy 
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cobegin 

a: ifx=0 —> b\ skipfi 
c: (x := l>[ 5 (c).£(c)] 
d : <skip) ( 5( d ) i t(d)] 
e : ifx=l — » /: skipfi 
Critical Section 1 

// 

a': ifx=0 — > 6': skip fi 
c': <x := 2 )[ 5 (c ') i ^c')] 

<*': <skip> (8(<0<e(<n ] 
e'\ ifx=2 — » /': skipfi 
Critical Section 2 

coend 

Figure 4.1. Mutual Exclusion Protocol 


(4.1) 5(c')+e(c , )<e(d) 

(4.2) 5(c)+e(c)<e(<0 

this protocol implements mutual exclusion of the marked critical sections. 

Mutual exclusion of afterie) and afterie') is a safety property. It can be proved by constructing 
a valid proof outline in which post(e) => — > after(e') and post(e') => — > afterie'). A standard approach 
for this is to construct a valid proof outline in which -i (post(e) a postie')) is valid. It is thus impos- 
sible for afterie) a afterie') to hold because that would imply post{e) a post{e'). 

A proof outline for one process is given in Figure 4.2; the proof outline for the other process is 
symmetric, with "1" everywhere replaced by "2" and the primed labels interchanged with unprimed 
ones. Notice that post(e)=$: c=l and post(e')=*x=2. Thus, the proof outlines satisfy the conditions 
just outlined for ensuring that states satisfying afterie) a afterie') cannot occur. 

It is not difficult to derive the proof outline of Figure 4.2 using the axiomatization of real-time 
actions given above. The proofs of { preic )} c {/wwr(c)} and [preid)} d {post id)} are the most 
enlightening, as they expose the role of assumptions (4.1) and (4.2) in the correctness of the protocol. 
Here is the proof of [preic)} c [postic)}: 

Assignment Axiom: 

1. [true } c:(x :=l> [S(tf)(£(c) ] {*=1} 

2. x=\ 

=> « Axiom (3.1)» 

x=\ a tatic’)< e T 
=> « assumption (4. 1)» 

x=\ a tar(c , )+5(c')+e(c , )-e(<f)<T' 

=> «Predicate Logic* 
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{true} 

<z : if jc= 0 — > {t 

b : skip 
{ tatic^ZT) 
fl {ta/fcO^T} 
c: <x := 1)[5(c),e(c)] 

{x*0 a (atic r ) => t ar(c 0 + 5(c 0 + e(c 0 -e(d) < tat{d )) } 
d : (skip)^),^)] 

{x*0 A-naKcO} 
e: ifx=l -» {x=l a-io^cO} 

/: skip 

{*=1 a-i<w(c')} 

fl (l=lA-ifl/(c')} 

Critical Section 1 

Figure 4.2. Proof Outline for Mutual Exclusion Protocol 


x*0 a Ta/fcO+SfcO+efO-eOOcT 
Rule of Consequence with 1 and 2: 

3. {true} c: <x := l) ( 8( C ).e(c)] {**0 a ta/(c , )+5(c , )+e(c , )-e(d)<T} 

Action-time Axiom (b): 

4. {K£T} c:<x:=l> [5(c ),e(c)] (KSt qfter(c)} 

Derived Tcp-Instantiation with 4: 

5. {ratCc^T} c:(x:= l)[8(c). e(c)] {Tat(c')£T<0er(c)} 

Conjunction Rule with 3 and 5: 

6. {t atijc^T} 

c: <x := 1>[S( C ),£( C )] 

{x^O a tar(c , )+5(c')+e(c , )-e((i)<TA tat(c')<,iafter{c)} 

7. tut(c , )+5(c')+e(c , )-e(d)<T a tatic^tafteric) 

=> ^assumption (4. 1) and Ta/irer(c)=Tar(d)» 

TarfcO+SCcO+efcO-eCd) < t at(d) 

=> ^Predicate Logic » 

at{c r ) => tat(c ')+5 (c')+£(c')- £( d) < r at(d) 

Rule of Consequence with 6 and 7: 

8. {rat(c')£T} c : (x := l) lS(c ) t E(c) ] {**0 a (ar(c')=^i'at(c')+5(c / )+e(c / )-e(<i)<Tar( < i))} 
And, here is the proof of {pre(d)} d { post(d )}. 
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skip Axiom: 

1 . {** 0 } d: (skip) [m ,t(d)] {** 0 } 


Real-time Action Axiom: 

2. {K£Ta*(d)} d: <skip> [8(<i)i e(d)] [K+e(d)<>Wter(d)} 

Rigid Variable Rule with 2, instantiating K with L+5(c')+e(c / )-e(^)+< where 0<ic 

3. {L+5(c')+e(cO-e(d)+K^Ta/(d)} 
d : {skip> ( 5(^ e(<0] 

{ L + 5(c y + e(c y -e(d) + k+ e(d) £ lafteiid ) } 

Predicate Logic, since 0<ic 

4. L+5(c')+£(cO-e(iO <tat(<i) => L + 5(c 0 + e(c 0 -e(<i) + tat(d) 

5. L + 5(c ') +e(c 0 - e(<i) + <+ e(<0 ^ lafterid) => L+SCcO+eCc') < ictfter{d) 

Rule of Consequence with 3, 4, and 5: 

6. {L+5(cO+6(c')-E(d)< T <H(d)} 
d : <skip>(5 (<i ) ( ^ 

{L+5(c')+e(c') < ta/ter(<0} 

Derived Tcp- Instantiation, replacing L by tatic 1 ): 

7. { tar(c 0 + 5(c 0 + e(c ') - e(d) < Tar(^) } 
d : (skip)^^ eW )j 

{ t<w(c , )+5(c / )+e(c') < tafter(d)} 

8 . tat(c , )+5(c')+£(c')<iqfter(d) 

=> « Axiom (3.1) applied to after{d)» 

TarfcO+SfcO+eCO < t qfter(d) S T 
=> «theorem (3.4) applied to ahO* 

-.otfc') 

Rule of Consequence with 7 and 8: 

9. (rar(c0+5(c0+e(c , )-e(d)<tat(d)} d: <skip> t5(<0 ,e<j)] {-.a/fcO} 

Process Independence Axiom: 

10. {-.ahc')} d : <skip ) [5W)i £(d)] {-.arfc')} 

Disjunction Rule with 9 and 10: 

11. (a/(c / )=>Taf(cO+5(c')+e(c')-e(d)<Tat(d)} d : (skip> [8Wi £(d)] {->at(c')} 
Conjunction Rule with 1 and 1 1 : 

12. {**0 a (at(c') => Tar(c ')+&(c')+e.(c')- e(d) < iat(d )) } 
d : (skip)(5 ( ^ i e( d )] 

{x*0 a -i at(c')} 


Notice how timing information is used in step 7 to infer that a particular control point cannot be 
active. 
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5. Discussion 

5.1. Other Work based on Proof Outlines 

It is instructive to compare our logic with that of [Shaw 89], another Hoare- style logic [Hoare 
69] for reasoning about execution of real-time programs. In [Shaw 89], the passage of time is 
modeled by augmenting each atomic action with an assignment to an interval-valued variable RT so 
that RT contains lower and upper bounds for the program’s elapsed execution time. The Statement 
Composition Rule and the Assignment Axiom are then used to derive rules for reasoning about these 
augmented atomic actions. 5 Our logic is obtained by augmenting the assertion language (of an under- 
lying logic of proof outlines) with additional terms (tcp and T) and devising new axioms for reason- 
ing about these terms. We are not able to derive rules for real-time actions by using the original logic 
because we do not employ assignment statements to model the passage of time. 

Although more complex, augmenting the axioms rather than the atomic actions has led us to a 
more powerful logic. First, having the tcp-terms allows the logic to be more expressive. These terms 
permit the definition of properties involving historical information — information that is not part of 
the current state of the program. Timing properties that constrain the elapsed time between events 
can only be formulated in terms of such historical information. The logic of [Shaw 89] has no way to 
express historical information and, consequently, can be employed to reason about only certain tim- 
ing properties. 

Second, our axiomatization allows reasoning about programs whose timing behavior is data- 
dependent The logic of [Shaw 89] does not permit such reasoning. For example, because of the way 
statement composition is handled in [Shaw 89], the logic produces overly-conservative intervals for 
time bounds. This is illustrated by the following program, which takes exactly 10 time units to exe- 
cute. 

if B skip [0 , 9 ] □ —>B -» skip[ 0 ,i) fi 

if B skip ( o,i] Q -i B skip[o,9] fi 

This fact can be proved in our logic; the logic of [Shaw 89] can prove only that execution requires 
between 2 and 18 time units. 

A Hoare-style programming logic for reasoning about real-time is also discussed in [Hooman 
91]. That work is largely incomparable to ours. First, the programming language axiomatized in 
[Hooman 91] is different, having synchronous message-passing and no shared variables. This is 
symptomatic of a fundamental difference in the two approaches. The emphasis in [Hooman 91] is on 
the design of compositional proof systems. Shared variables cannot (at present) be handled composi- 
tionally and so they are excluded from programs. In contrast, we do not require that our proof system 
be compositional. 6 Relaxing this compositionality requirement means that it is not difficult to extend 
our logic for reasoning (non-compositionally) about programs that employ synchronous message- 
passing or any of the other communication/synchronization mechanisms for which Hoare-style 
axioms have been proposed. 


5 The idea of augmenting actions with assignment statements in order to reason about the passage of time is discussed 
in [Haase 81], where it is used to extend Dijkstra’s wp [Dijkstra 75] for reasoning about elapsed execution time. 

^The cobegin Rule of Proof Outline Logic is not compositional because its interference -freedom test depends on the 
internal structure of the processes being composed. 
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The types of properties handled in [Hooman 91] is also incomparable to what can be proved 
using our logic. Timing properties make visible the times at which control points become active 
through Tcp-terms. A compositional proof system cannot include information about control points in 
its formulas because they betray the internal structure of a component The logic of [Hooman 91], 
therefore, may only be concerned with the times at which externally visible events occur: the time of 
communications events and the time that program execution starts and terminates. This turns out to 
allow proofs of certain liveness properties as well as certain safety properties. Our logic cannot be 
used to prove any liveness properties. 

5.2. Incompleteness Concerns 

A soundness proof for the logic of this paper will appear elsewhere. The issue of completeness, 
however, is a bit problematic. The following proof outline illustrates the difficulties. It is valid, but 
is not provable with our logic. 

(5.1) [T=0] a : skip [0 , 2 j [T=2] b: skip (0>2 ] [7=4} 

A related proof outline is provable: 

(5.2) {0£taf(a)£TS2} a:skip [0> 2 ] {2^tar(6)^T^4} b: skip (0>2 j {4<,^(rfter{b)<x‘T\ 

Notice that the assertions of (5.2) characterize system states that would exist "during" the execution 
of a and b\ the assertions of (5.1) do not. 

A deficiency in our logic is one explanation for this situation; a deficiency in the definition of 
proof outline validity is another. Proof outline validity is defined in terms of a set (Xs) of infinite 
state sequences that model execution of S started from any program state. This set contains no 
sequence whose successive states differ only in their values of % the states that assertions in (5.2) 
characterize and those in (5.1) do not. Certainly such states exist during program execution; we have 
simply chosen to define X$ so that states are recorded only when the value of some tcp-term 
changes. Now consider a set that does contain sequences having such temporal interpolation 
states. If we replace “Ms in Valid Proof Outline (2.7) by then (5.2) remains valid and (5.1) 
becomes invalid. The incompleteness problem is gone. 

There are also other reasons to prefer in defining proof outline validity. Invariance under 
temporal interpolation seems to be the real-time analog of invariance under stuttering, something that 
is critical when proving that one specification or a program implements another. Unfortunately, the 
logic of this paper is unsound when X^ is used in place of Xs*. The existence of temporal interpo- 
lation states causes a new form of interference. This interference is easily dealt with by extending the 
definition of interference freedom. 

Another concern when designing a logic is expressive completeness. Timing properties include 
many, but not all, safety properties of concern when reasoning about the behavior of real-time pro- 
grams. This is because the historical information in a timing property is limited to times that control 
points become active. One might also be concerned with the elapsed time since the program vari- 
ables last satisfied a given predicate or with satisfying constraints about how the program variables 
change as a function of time. Both are safety properties but neither is a timing property (according to 
our definition in §1). In general, safety properties can be partitioned into invariance properties and 
history properties. The invariant used in proving an invariance property need only refer to the current 
state; the invariant used in proving a history property may need to refer to the sequence of states up to 
the current state. Timing properties are a type of history property. 


A version of Proof Outline Logic does exist for reasoning about history properties [Schneider 
92]. It extends ordinary Proof Outline Logic by augmenting the assertion language with a "past state" 
operator and a function-definition facility. In this logic, our tcp-terms can be constructed explicitly; 
they need not be primitive. And, the more general class of safety properties involving times — be it 
times that predicates hold or times that control predicates hold — can be handled. 
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